home *** CD-ROM | disk | FTP | other *** search
- From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
- From: "Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>
- Date: Sun, 6 Mar 94 02:52:34 PST
- From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
- Message-Id: <9403061052.AA23538@hanauma.jpl.nasa.gov>
- To: entropy@terminator.rs.itd.umich.edu, miff@asharak.apana.org.au
- Subject: Re: another 1.10 job control bug?
-
- From: "Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>
- >From: miff@asharak.apana.org.au (michael smith)
- >In <199403042253.RAA07033@terminator.rs.itd.umich.edu> you wrote :
- >>My only problem with it as a permanent solution is that a process
- >>hanging around in the foregroung process group could prevent the
- >>controlling tty from ever being released, causing the
- >>you-only-get-one-login-per-device problem again. One way this could
- >>happen is if an asynchronous process is spawned from a
- >>non-job-control-aware shell (e.g. one that knows nothing about process
- >>groups). I guess this isn't a big enough problem to be concerned
- >>about at the moment, unless there are other ways this could happen.
- >
- >Hmm, and it shouldn't be a problem anyway - when DCD drops/the TCP link is
- >closed/or any other 'true' logout action occurs, init should terminate
- >all processes that claim to have that line as a controlling tty.
- >
- >I don't think init has enough information to do this. Under MiNT this
- >should be under the kernel's control. And even if the kernel did
- >handle this, it would only apply if the CLOCAL bit were not set in the
- >tty flags, and would only have the desired effect if the process
- >doesn't ignore SIGHUP (for instance, users should be able to start a
- >daemon interactively from the modem1 tty using a non-job-control aware
- >shell, then log out, and expect the port not to get locked up.)
-
- Hm, I can't remember how BSD invalidates the tty descriptor of background
- jobs. Certainly init should reset the process group of the tty when the
- child that was spawned on it terminates. That in itself should prevent
- any remaining jobs from writing, eh? But there must be more to it. Yah,
- SunOS uses sessions *now*, but what was before them? (Dang, can't find
- my 4.3 internals book right now...)
-